Add a SQL Statement Execution fake to the testserver#5432
Merged
Conversation
Introduce libs/testserver/testsql, a pluggable fake of the SQL Statement Execution API. Tests register matchers via Server.HandleSQL / HandleSQLPattern that map a statement to a declarative result (columns, rows, optional error, poll count, chunk count); the testserver models the full lifecycle (submit, poll, chunk pagination, cancel) over the real HTTP endpoints. Migrate libs/sqlexec's HTTP tests onto this fake so they no longer hand-build StatementResponse stubs per test. Co-authored-by: Isaac
A live cross-check against the real Statement Execution API showed that a statement returning no rows (a 0-row SELECT or a no-result-set DDL) responds with total_chunk_count=0 and an empty result, not a single empty chunk. Match that: splitChunks yields zero chunks for empty input and the terminal response inlines data only when a chunk exists. Co-authored-by: Isaac
Document on Result.Rows that a SQL NULL and an empty string are indistinguishable: the API wire format encodes NULL as JSON null, but the SDK models result cells as [][]string, so JSON null decodes to "". Recovering the distinction would require a null-aware cell type or the ARROW_STREAM format, which no caller needs today. Co-authored-by: Isaac
The Statement Execution API populates status.sql_state (SQLSTATE) on failures (e.g. 42P01 for a missing relation), confirmed against a live warehouse. Assert it survives into StatementError so the contract is covered. Co-authored-by: Isaac
Move the SQL Statement Execution lifecycle routes from testserver.New into AddDefaultHandlers. Registering them in New made them permanent first-wins registrations, so tests could not install raw handlers for those paths (needed for malformed bodies, transport errors, or custom status codes the testsql fake does not model). As default handlers they are overridable: a raw Server.Handle for the same pattern registered before AddDefaultHandlers wins, as do test.toml stubs in acceptance. The libs/sqlexec HTTP tests opt in via a newServer helper. Co-authored-by: Isaac
denik
approved these changes
Jun 4, 2026
denik
left a comment
Contributor
There was a problem hiding this comment.
Is it going to be integrated into acceptance testrunner & config? A selftest would be nice to see what it can do.
Add an HTTP test that registers a regex matcher and echoes back a captured submatch, exercising Server.HandleSQLPattern and Request.Match end-to-end. This was the only SQL-exec path without coverage; it also gives HandleSQLPattern a caller (the deadcode check flagged the Server-level wrapper as unreachable). Co-authored-by: Isaac
Revert the sqlexec HTTP regex test (b48cd77): the regex matcher lives in the testsql engine and is covered there (TestPatternDispatchSubmatches etc.), so exercising it through an sqlexec round-trip tested the wrong layer. The only reason that test existed was to give Server.HandleSQLPattern a caller; without it the wrapper is unreachable, so remove it. The engine's HandlePattern stays; a Server-level wrapper returns with its first real consumer (metric views). Co-authored-by: Isaac
Bring back Server.HandleSQLPattern (removed in the previous commit) and cover it together with HandleSQL via local testserver tests that drive the POST handler directly. This keeps the regex matcher in the public testserver API and tested on the testserver side, rather than through an sqlexec round-trip. Co-authored-by: Isaac
Contributor
Author
|
@denik Yes, that's the idea eventually. |
Collaborator
|
Commit: 3eef5e7 |
Collaborator
|
Commit: e92f999 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
libs/testserver/testsql, a pluggable fake of the SQL Statement Execution API, so tests can drive/api/2.0/sql/statementsnatively instead of hand-buildingStatementResponsestubs.Tests register matchers via
Server.HandleSQL(exact) /Server.HandleSQLPattern(regex), each mapping a statement to a declarative result — columns, rows, an optional error, a poll count, and a chunk count. The testserver models the full lifecycle over the real HTTP endpoints: submit (honoringwait_timeout), poll, chunk pagination, and cancel. A matcher runs once per submission, so a matcher that closes over a map can model stateful resources (create then read back).The lifecycle routes are registered in
AddDefaultHandlersas overridable defaults: a rawServer.Handlefor the same pattern registered beforeAddDefaultHandlerswins, as dotest.tomlstubs in acceptance — preserving an escape hatch for responses the fake doesn't model (malformed bodies, transport errors, custom status codes).The
libs/sqlexecHTTP tests are migrated onto the fake, replacing per-testStatementResponseconstruction with one-line matchers.Cross-check against the real API
Behaviors were verified against a live SQL warehouse, which drove three refinements:
SELECTor no-result-set DDL) reportstotal_chunk_count: 0with an empty result; the fake now matches (previously it always emitted one empty chunk).status.sql_stateis populated on failures (e.g.42P01); added an assertion to the failed-statement integration test so the typedStatementError.SQLStatecontract is covered.Result.Rowsthat SQLNULLand empty string are indistinguishable there: the wire format encodesNULLas JSONnull, but the SDK models cells as[][]string, sonulldecodes to"". Recovering the distinction would need a null-aware cell type or theARROW_STREAMformat; no caller needs it today.Test plan
sqlexecintegration suite passes live (TestSQLExec*, incl. the newSQLStateassertion).This pull request and its description were written by Isaac.